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BACKGROUND OF THE INVENTION 
[0001] This invention relates to the art of telecommunications and more 

particularly to a system and method for routing a call in a wireless communications 

network made to a called party universal destination identifier. 

[0002] Wireless communications networks, also known as cellular networks, 

have been widely adopted around the world. These telecommunications systems 

can do more than transfer voice calls. A wide variety of different calls transferring a 

wide variety of different types of media can now be made over a wireless 

communications network. 

[0003] A user, also known as a subscriber, can have a wide variety of devices 

on which they wish to receive calls. Currently, each device can only be reached by 
the calling party using the corresponding destination identifier for that device. A 
calling party placing a call to the subscriber, also referred to as the called party, will 
have to keep track of the plurality of different "numbers" for reaching the appropriate 
called party device. 

[0004] It is desirable to provide a called party with a single point of contact 

whereby the called party can receive different call types at different destinations, 
each destination corresponding to a specific device intended for receiving that 
particular call type. 
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SUMMARY OF THE INVENTION 
[0005] A system and method of routing calls in a wireless communications 

network using a single point of contact is provided. 

[0006] In accordance with a first aspect of the invention, the method includes 

determining the call type, selecting a call-type-specific destination identifier for the 
call from a plurality of called party destination identifiers based on the call type, and 
routing the call to the called party using the selected call-type-specific destination 
identifier. 

[0007] In accordance with a second aspect of the invention, the step of 

determining the call type can include determining the call protocol, determining the 
media type, and determining the call type from the call protocol and the media type. 
[0008] In accordance with another aspect of the invention, the system 

includes means for determining the call type, means for selecting a call-type-specific 
destination identifier for the call from a plurality of called party destination identifiers 
based on the call type, and means for routing the call to the called party using the 
selected call-type-specific destination identifier. 

[0009] Further scope of the applicability of the present invention will become 

apparent from the detailed description provided below. It should be understood, 
however, that the detailed description and specific examples, while indicating 
preferred embodiments of the invention, are given by way of illustration only, since 
various changes and modifications within the spirit and scope of the invention will 
become apparent to those skilled in the art. 



DESCRIPTION OF THE DRAWINGS 
[0010] The invention may take form in various components and arrangements 

of components, and in various steps and arrangements of steps. The drawings are 
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only for purposes of illustrating preferred embodiments and are not to be construed 
as limiting the invention. Further, it is to be appreciated that the drawings are not to 
scale. 

[0011] FIG. 1 is a diagrammatic illustration showing an exemplary 

telecommunications environment suitable for practicing aspects of the present 
invention; 

[0012] FIG. 2 is a flow chart illustrating a method routing a call made to a 

single point of contact in accordance with the invention; 

[0013] FIG. 3 is a flow chart illustrating a method determining the call type in 

accordance with the invention; 

[0014] FIG. 4 is a message flow illustrating the system and method of routing 

a call in wireless communications network in accordance with the invention; and 
[0015] FIG. 5 is a message flow illustrating an example of the system and 

method of routing a call in wireless communications network in accordance with the 
invention. 

DETAILED DESCRIPTION OF THE INVENTION 
[0016] For simplicity and ease of reference, the following acronyms shall be 

used in the present specification to refer to structural and/or functional network 
elements and/or entities, relevant telecommunications standards, protocols and/or 
services, terminology, etc., as they are commonly known in the telecommunications 
art, except to the extent they have been modified in accordance with aspects of the 
present invention: 

[0017] 3G - 3 rd Generation 

[0018] 3GPP - 3 rd Generation Partnership Project 
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[0019] 


3GPP2 - 3 rd Generation Partnership Project 2 


[0020] 


AAA - Authentication/Authorization/Accounting 


[0021] 


AH - Address Handling 


[0022] 


AS - Application Server 


[0023] 


BGCF - Border Gateway Control Function 


[0024] 


CCF - Call Control Function 


[0025] 


CDMA - Code Division Multiple Access 


[0026] 


CSCF - Call Session Control Function 


[0027] 


HLR - Home Location Register 


[0028] 


HSS - Home Subscriber Server 


[0029] 


ICGW - Incoming Call Gateway 


[0030] 


IMS - IP Multimedia Subsystem 


[0031] 


IP - Internet Protocol 


[0032] 


MGCF - Media Gateway Control Function 


[0033] 


MGW - Media Gateway 


[0034] 


MMT - Multimedia Terminal 


[0035] 


MRFC - Multimedia Resource Function Controller 


[0036] 


MRFP - Multimedia Resource Function Processor 


[0037] 


PDN - Public Data Network 


[0038] 


PLMN - Public Land Mobile Network 


[0039] 


PSDN - Packet Switched Data Network 


[0040] 


PSTN - Public Switched Telephone Network 


[0041] 


PTT - Push-to-Talk 


[0042] 


RAN - Radio Access Network 


[0043] 


SIP - Session Initiation Protocol 
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[0044] SMS - Short Message Service 

[0045] SMT - Single Media Terminal 

[0046] SPD - Serving Profile Database 

[0047] UMTS - Universal Mobile Telecommunications System 

[0048] VOIP - Voice over IP 

[0049] WLAN - Wireless Local Area Network 



[0050] With reference to FIGURE 1, an optionally 3GPP/3GPP2 compliant 

telecommunications environment or network 10 is equipped and/or arranged to 
manage and/or route multimedia communications between terminals employing the 
same. Other suitable telecommunications environments, however, may be 
employed. The network 10 includes an IMS 20 that incorporates in the usual 
manner a number of network entities and/or elements, namely, one or more of a 
CSCF 22, AS 24, MGW 26, MGCF 28, BGCF 30, MRFP 32, MRFC 34, HSS 36. As 
is known in the art, the IMS 20 manages call sessions and provides and administers 
packet switching for multimedia communications within the network 10. 
[0051] For exemplary purposes, an MMT 40 also referred to as the calling 

party terminal or calling party, is shown as a mobile MMT (namely, a multimedia 
enabled mobile phone as is commonly known) that is operatively connected to the 
IMS 20 via a RAN 42. The RAN 42, as it is known, is that portion of a mobile network 
that handles subscriber access, including radio base stations and control and 
concentration nodes, i.e., the portion relating to "over the air" communications 
between the mobile terminal and the network base station. A packet data subsystem 
44 interfaces the RAN 42 with the IMS 20 and PDN 52 in the usual manner. 
[0052] Another MMT 50, referred to a the called party terminal is shown as a 

laptop or notebook type computer operatively connected to the IMS 20 via a PDN 
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52. The MMT 50 optionally employs a WLAN or wire line, in the usual manner, to 
operatively connect to the PDN. 

[0053] An SMT 60, also referred to as the called party terminal is shown as an 

ordinary telephone equipped to handle only voice communications. The SMT 60 is 
operatively connected to the IMS 20 via a PSTN/PLMN 62. 
[0054] Only a first 50 and second 60 called party terminal are shown in 

FIGURE 1 for the purpose of simplicity herein. However, it is to be appreciated that 
typically a plurality of called party terminals are similarly situated. Additionally, while 
depicted as a specific type of MMT or SMT, other suitable terminals capable of 
communicating over the wireless communications network 10 are also 
contemplated. 

[0055] With continuing reference to FIGURE 1, the bearer paths, as are 

known in the art, that carry and/or relay the communication traffic and/or user 
information intended to be transmitted from one terminal to another are shown as 
solid lines. Control paths, as are known in the art, carry and/or relay associated 
signaling and/or control commands or messages to and between appropriate 
network elements and/or entities such that call sessions are properly managed and 
routed. The control paths are shown as dashed lines in FIGURE 1. Suitably, SIP 
and/or other appropriate known protocols are used on the control and bearer paths, 
respectively, e.g., the known H.248 protocol is suitably employed for media gateway 
controls. The CSCF 22, BGCF 30, MGCF 28, MRFC 34 and AS 24 comprise the call 
control and signaling functionality for the IMS 20, while the bearer paths interface 
with the MRFP 32 and MGW 26 to provide and support interconnectivity to external 
networks and/or subsystems, such as, the packet data subsystem 44, PDN 52 and 
PSTN/PLMN 62. 
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[0056] The CSCF 22 supports and controls multimedia sessions. The CSCF 

22 invites the MGCF 28 and/or MRFC 34 to call sessions to control the 
establishment and maintenance of bearer paths for call sessions, e.g., by adding, 
modifying or deleting appropriate bearer paths for respective call sessions. The 
CSCF 22 is the signaling entity for call session control. It manages sessions (e.g., 
using SIP and/or other appropriate call/session establishment protocols), provides 
features and services and coordinates with other network elements for session 
control, service control and resource allocation. The CSCF 22 performs several 
functions including Incoming Call Gateway (ICGW) in which it acts as a call session 
entry point and routes incoming calls to the called party destination. 
[0057] The CSCF 22 also performs Call Control Function (CCF) in which it 

executes call setup/termination and state/event management. It interacts with the 
MGCF 28 for calls to/from the PSTN/PLMN 62, and with the BGCF 30 for calls to the 
PSTN/PLMN 62 to determine the appropriate MGCF 28 to use. It also controls the 
MRFP 32 via the MRFC 34 (which interprets information or signals coming from the 
CSCF 22 and controls the MFRP 32 accordingly) in order to support conferencing 
and other multi-party services. SIP level registrations from subscribers are 
processed in CCF. The CCF may provide service trigger mechanisms to the AS 24 
to invoke services provided thereby (either locally, at the AS 24, or elsewhere). It 
also reports call events for billing, auditing, intercept or other purposes, and may 
query the AS function to check whether a requested communication is allowed given 
the current subscription. 

[0058] The CSCF 22 also provides a Serving Profile Database (SPD) in which 

it interacts with the HSS/AAA 36 to receive and cache user profile information. 
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[0059] The CSCF 22 also performs Address Handling (AH) in which it 

performs address analysis, translation, modification (when appropriate) and 
mapping. 

[0060] The MGW 26 acts as a bearer path interface between the IMS 20 and 

externals networks and/or subsystems, and provides translation resources and 
resources for modifying the bearer stream (e.g., encoding, transcoding, 
compression, packetization, depacketization, etc.). It interacts with the MGCF 28 
(which interprets signaling coming from the CSCF 22 and controls the MGW 26 
accordingly) in order to achieve resource allocation, bearer path control, and 
payload processing. The MGCF 28 communicates with the CSCF 22 in order to 
control the call state for media channels on one or more MGWs and performs 
conversions between legacy and 3G UMTS/CDMA network call control protocols. 
Similarly, the MRFC 34 controls the media stream resources in the MRFP 32 which 
also acts as a bearer path interface between the IMS 20 and external networks 
and/or subsystems, however, being able to provide for conferencing or multiple party 
communications or other more advanced media services (relative to the MGW 26). 
[0061] The HSS 36 maintains subscriber and system related data, user 

profiles, locations, etc. Optionally, the HSS 36 also contains what is known as the 
HLR functionality and/or AAA function. Suitably, the HSS database can include: user 
identification, via numbering and addressing information; user security information, 
including network access control information for authentication and authorization; 
user location information for user registration and locating; and a user profile, 
including identification of the services subscribed to and other service specific 
information. The HSS 36 also includes one or more call-type-specific destination 
identifiers associated with a called party by a single point of contact as described 
below. 
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[0062] Referring now to Figs. 2 and 3, a method of routing a call in a wireless 

communications network using a single point of contact, also referred to as a 
Subscriber Universal Destination Identifier (SUDI), is shown generally at 100. The 
method 100 includes calling a called party SUDI at 102. The SUDI can be a phone 
number or a Uniform Resource Identifier (URI). A URI can be used to identify points 
of content, such as a page of text, a video or sound clip, a still or animated image, or 
a program. Examples of a URI can include, but are not limited to, a Uniform 
Resource Locator (URL) such as an Internet Protocol (IP) address, a Uniform 
Resource Name (URN), a Session Initiation Protocol (SIP) address, or an E.164 
number. 

[0063] A URI can describe the mechanism used to access the resource at the 

destination, such as the specific computer that the resource is housed in at that 
destination, and the specific name of the resource, such as for example a file name 
on the computer. As an example, a URI may be: 

http://www.w3.orq/lconsA/\A/VW/w3c main.aif . This URI identifies a file that can be 
accessed using the Web protocol application, Hypertext Transfer Protocol, ("http://") 
that is housed on a computer named "www.w3.org" (which can be mapped to a 
unique Internet address). In the computer's directory structure, the file is located at 
the pathname of 7lcons/WWW/w3c_main.gif." Character strings that identify File 
Transfer Protocol FTP addresses and e-mail addresses are also URLs and thus are 
URIs. A URN is a form of URI that has "institutional persistence," such that its exact 
destination may change from time to time, but an agency accessed by the URN will 
be able to find it. 

[0064] A wireless subscriber can use a single SUDI to receive plurality of 

different call types over the wireless communications network 10. Examples of the 
call types can include, but are not limited to, voice calls, a data session for 
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transferring data over the wireless communications network, and SMS text 
messages, video sessions, or a combination of these which can be referred to as 
multimedia sessions. The single SUDI can be used to route calls of different call 
types to different destinations indicated by corresponding call-type-specific 
destination identifiers. Examples of these destinations can include, but are not 
limited to a wireless communications terminal or a wireline terminal for voice calls, a 
computer or a multimedia wireless terminal for data transmissions. The called party 
can specify the different destinations for different call types using call-type-specific 
destination identifiers. More than one call type can be sent to a destination identified 
by a call-type-specific destination identifier. 

[0065] Calling the called party SUDI at 102 generates one or more call control 

commands, referred to generally as a "call request", at 104. As shown by way of 
example in Fig. 4, the call request 202 is sent to the CSCF 22. The call request 202 
can be made using any suitable call control command or commands using any 
suitable protocol. The call request 202 typically includes a session ID, an indicator 
of the Originating Host (the calling party), and an indicator of the Destination Host 
(as identified by the SUDI). The call request 202 can include a media descriptor as 
described below. 

[0066] The method 100 also includes determining the call type at 106. The 

CSCF 22 can determine the call type at 106 from the call request 202. Referring to 
Fig. 3, the step of determining the call type at 106 is shown in further detail. The 
CSCF 22 determines the call protocol used in the call control signaling of the call 
request at 108. If the call protocol does not support multiple call types at 110, the 
call type is determined from the protocol used for the call request at 112. In an 
example, which should not be considered limiting, if the call request is made using 
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ISUP signaling which supports only voice calls then the CSCF 22 determines that 
the call type is an ISUP voice call from the call protocol at 112. 
[0067] If the call protocol used for the call request does support multiple call 

types at 110, the method 100 also includes determining the media type at 114. The 
media type is the type of media that will be transferred by the call, examples of 
which can include, but are not limited to "audio", "video", "application", "data" and 
"control", among others. The difference between "application" and "data" is that the 
former is a media flow such as whiteboard information, and the latter is bulk-data 
transfer such as multicasting of program executables which will not typically be 
displayed to the user. "Control" is used to specify an additional conference control 
channel for the session." The media type can be determined from the media 
descriptor included in the call request 202. The media descriptor can be any 
indicator of the media type to be transferred in the call that is included in the call 
request. 

[0068] The CSCF 22 uses the call protocol and the media type to determine 

the call type at 116. In an example, which should not be limiting, the call request is 
made using SIP signaling call control protocol when the calling party calls the called 
party SUDI at 102. The SIP protocol can support more than one call type. 
Therefore, the CSCF 22 determines the media type to be transferred in the call from 
the media descriptor included in the call request at 114. In SIP, the media type is 
described within the Session Description Protocol (SDP) which is defined in IETF 
(Internet Engineering Task Force) RFC 2327. The SDP indicates the media type 
using a media descriptor media line, such as for example a line starting with 'm- 
that indicates the media type. However, other conventions/protocols can be used 
and the media type can be determined from the media descriptor used therein. 
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[0069] The media may be transferred as a media payload type as defined in 

the RTP (Real-Time Transport Protocol) Audio/Video Profile. In this example, a 
subfield contains a payload type number which is used to identify a particular 
payload type format. There can be additional attribute lines to define details of the 
format, such as for example attribute lines commencing with 'a=\ An example of the 
media type from the RFC2327 protocol, which should not be considered limiting, can 
include a static payload type u-law PCM coded single channel audio sampled at 
8KHz, as defined in the RTP Audio/Video profile as payload type 0. The media 
descriptor used to determine the media type for such a stream sent to UDP port 
49232 is: 

m=video 49232 RTP/AVP 0 

The call type is determined to be an RTP call having the media type described 
above. 

[0070] As another example, a dynamic payload type, such as for example 16 

bit linear encoded stereo audio media sampled at 16KHz, can include a media type 
as defined by a media descriptor using a dynamic RTP/AVP payload type 98 with: 

m=video 49232 RTP/AVP 98; and 
a=rtpmap:98 L1 6/1 6000/2 

The call type is determined to be an RTP call having the media type described 
above. 

[0071] Referring now to Figs. 2 and 4, the method 100 also includes 

determining a call-type-specific destination identifier (CDI) at 120. The CDI identifies 



13 

the destination that the call having the call type as determined at 106 is routed to. 
The CDI can identify any destination suitable to the call type to which a call can be 
routed to over a wireless communications network 10. Examples can include, but 
are not limited to a phone number of a wireless communications terminal, the phone 
number of a wireline terminal, an IP address, etc. 

[0072] The CDI can be determined by the CSCF 22, the HSS 36, or any other 

suitable network node in the wireless communications network 10. In the examples 
described herein, which should not be considered limiting, the CDI is determined by 
the HSS 36. After determining the call type at 106, the CSCF 22 sends a 
Location_lnfo_Request 204 to the HSS 36. The Location_lnfo_Request 204 
includes the call type, the originating host and the SUDI. The HSS determines the 
CDI at 120 using the SUDI and the call type. For example, the CDI can be 
determined via a table lookup once the SUDI and call type are known. A plurality of 
CDIs can be provisioned at the HSS for a variety of call types, by the subscriber or 
by the network provider. The subscriber can provide the network 10 with a CDI for 
each corresponding call type. For example, all call types transferring data are to be 
sent to a destination identified by CDI #1 (e.g. IP address of computer), all ISUP 
voice calls are to be sent to a destination identified by CDI # 2 (e.g. a wireline 
terminal phone number), for all SMS messages are to be sent to a destination 
identified by CDI # 3 (e.g. a wireless terminal), etc. 

[0073] The HSS 36 sends a Location_lnfo_Answer 206 back to the CSCF 22 

which includes the CDI for the call type determined at step 106. The CSCF 22 then 
routes the call to the call-type-specific destination as identified by the CDI at 122. 
[0074] Referring now to Fig. 5, a message flow illustrating another example is 

shown generally at 300. In this example, the calling party 40 places an audio call, 
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that is a normal voice call, to the called party using a SIP SUDI = 
sip:anniebp@lucentcom. 

[0075] As shown in part A of the message flow 300, the call request 202 is an 

INVITE message from the calling party terminal 40 to the CSCF 22. The call request 
(INVITE message) includes a media descriptor: 
[0076] m=audio xxxx RTP/AVP 0. 

[0077] The CSCF 22 uses the call request to determine that the call protocol 

is SIP. Further, since the SIP call protocol can support more than one call type by 
being able to transfer more than one media, the CSCF 22 determines the media 
type from the media descriptor as an 'audio 1 call on port number xxxx and the codec 
is 0 which stands for G71 1 mu-law. The CSCF 22 therefore determines the call type 
to be a SIP audio/G71 1 call. 

[0078] In part B, The CSCF 22 makes the Location Info Request (LIR) query 

to the HSS 36 which includes the call type (SIP audio/G71 1) and the SUDI. The 
HSS 36 determines the CDI at 120 using the call type and SUDI and responds to the 
Location Info Request query by sending a Location Info Answer (LIA) back to the 
CSCF 22 which includes the CDI for that call type. In this example, the CDI is a 
telephone number, 212-555-1212, for a terminal where the called party wants to 
receive SIP audio/G71 1 calls. 

[0079] In part C, the call is routed to the destination using the CDI in a known 

manner. The CSCF 22 sends an INVITE message to the appropriate MGCF 28 to 
route to the call to destination telephone number. The MGCF 28 in turn sends an 
I AM (initial address message) to the PSTN 62 to set up the call. H.248 messages 
are sent to the MGW 26 to set up the bearer interconnection from IP to TDM. 83 
Session Progress and 180 Ringing messages are returned to the calling party 40 to 
indicate that the call is being set-up. Once the call is answered by the PSTN 62 an 
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ANM (Answer Message) is returned to the MGCF 28, which in turn sends a 200OK 
SIP message to the CSCF 22 and then to the calling party 40. And ACK 
(Acknowledge message) is returned and the bearer path for the call is established 
and the call is routed to the destination/device indicated by the call-type-specific 
destination identifier. 

[0080] It is also to be appreciated that particular elements or components 

described herein may have their functionality suitably implemented via hardware, 
software, firmware or a combination thereof. Additionally, it is to be appreciated that 
certain elements described herein as incorporated together may under suitable 
circumstances be stand alone elements or otherwise divided. Similarly, a plurality of 
particular functions described as being carried out by one particular element may be 
carried out by a plurality of distinct elements acting independently to carry out 
individual functions, or certain individual functions may be split-up and carried out by 
a plurality of distinct elements acting in concert. Alternately, some elements or 
components otherwise described and/or shown herein as distinct from one another 
may be physically or functionally combined where appropriate. 
[0081] The above description merely provides a disclosure of particular 

embodiments of the invention and is not intended for the purposes of limiting the 
same thereto. As such, the invention is not limited to only the above-described 
embodiments. Rather, it is recognized that one skilled in the art could conceive 
alternative embodiments that fall within the scope of the invention. 



